The present invention relates to computers and, more particularly, to computer bridge interfaces. A major objective of the present invention is to facilitate the development of accessories for the Handspring computer platform.
Much of modern progress is associated with the prevalence of computers, which are assuming an increasing variety of forms. Increasingly popular are hand-held computers that include software for helping people to organize information such as phone numbers, addresses, schedules, finances, etc. Such handheld computers are often referred to as xe2x80x9cpersonal digital assistantsxe2x80x9d or xe2x80x9cPDAsxe2x80x9d. Provisions are made for adding software to provide for additional applications so that a user can extend the functionality of a PDA, while maintaining its familiar interface.
The most popular PDA recently has been the Palm Pilot available from 3com. The user interface is considered intuitive, and software development for the Palm Pilot has become an industry of its own. However, hardware expandability of the Palm Pilot is limited. This has contrained the development of applications that could benefit from the Palm Pilot interface, but require more or different processing capabilities that the xe2x80x9cDragonballxe2x80x9d processor used by the Palm Pilot.
The Visor, available from Handspring, Incorporated, is similar to the Palm Pilot and shares its user interface and operating system. The Visor differs from the Palm Pilot since it includes a mechanism (the xe2x80x9cSpringboard Expansion Slotxe2x80x9d) for hardware expansion. The specifications for this expansion slot have been publised by Handspring to encourage the development of expansion modules to extend the capabilities of the visor. The interface for the expansion slot is described in detail in the xe2x80x9cDevelopment Kit for Handspring Handheld Computersxe2x80x9d available at the Handspring website www.handspring.com. In view of the publication of the interface specifications and active encouragement by Handspring to third party developers, it is likely that there will be intense Visor-compatible hardware development efforts.
While it is an important advance for devices with the Palm Pilot interface, the expansion slot has significant limitations. The logical bus interface for the Springboard expansion slot is a xe2x80x9cslavexe2x80x9d-only bus interface in which the Dragonball processor is the master and the expansion module is the slave. Basically, the Dragonball processor can initiate 16-bit reads and writes from and to the expansion module. Module-initiated communications are limited to a single interrupt. Additional control signals are provided to provide for hot-swapping (exchanging without powering down the PDA) expansion modules and for power management.
Buses that have higher-performance and that are more flexible than the Springboard expansion bus are well known. For example, multi-master buses provide for parallel processing among different masters that communicate with each other and slave peripherals over the bus in a time-multiplexed manner. Many of these buses provide for variable wait states to provide flexible timing, while the Springboard expansion slot does not. A good example of such a multi-master bus is the Advanced System Bus or ASB that can be used with ARM7 processors for system-on-a-chip designs. The ASB and ARM7 specifications are available from Arm Limited, of the United Kingdom.
An ARM7 (more specifically, an ARM7TDMI) can be coupled to an ASB bus through an ARM7TDMI-to-ASB-Bus interface, available from Philips Electronics. The ASB bus can issue wait and grant signals that can affect the timing of data transfer requests originated by the ARM7 processor. These xe2x80x9chandshakingxe2x80x9d signals allow timing to vary on a per-transaction basis, which facilitates data transfers in an environment with a variety of peripherals with different timing requirements and/or multiple masters.
In contrast, the Springboard expansion bus does not provide for handshaking with the expansion module. Instead, transactions are xe2x80x9cpresumedxe2x80x9d complete after a predetermined lapse of time. An expansion module can set this lapse of time upon insertion into the Springboard expansion slot. The expansion module must be designed so that all transactions are complete by the time the Visor presumes they are complete; otherwise, serious errors can result.
Associated with each bus is a specification that includes physical and logical protocols to which master and slave peripherals must conform. Typically, when a new bus is introduced, many peripherals are designed to be compatible with it. Some of these may be designed from the circuit level, while others may involve modifications of designs conforming to other bus standards.
If the bus is adopted for many applications, a library of peripheral design modules is often developed. This permits a modular approach to produce design, which greatly facilitates product development and reduces the time between conception and market entry. Such time-to-market advantages are critical in highly contested market areas, such as that expected for Handspring expansion modules.
The relatively simplicity of the Springboard expansion bus is certainly facilitates product development to a point. However, the functional limitations of the bus present a challenge, as the market demands more powerful expansion modules. What is needed is a system that provides for rapid development of powerful expansion modules for Springboard and similar expansion buses.
An expansion module for a Handspring Visor (which conforms to the Springboard bus specification) includes a multi-master AMBA Advanced System Bus (ASB). Optionally, an Arm7 processor is attached to this bus via an Arm7 to ASB interface as one master. The Springboard bus of the visor is coupled to the ASB bus via Springboard-to-ASB-bus bridge. This bridge comprises a protocol translator and a second Arm7 to ASB interface. The protocol translator translates bi-directionally between the Springboard bus protocol and the Arm7TDMI protocol. The translator includes an interface to the Springboard bus and a state machine. The state machine coordinates data transfers between the buses. The state machine also monitors signals indicating when each of said buses begins to treat a data transfer as complete so that the data transfer can be validated or flagged as an error condition. A programmable counter adjusts maximum counts to compensate for different clock frequencies in measuring a write-wait state duration to ensure valid writes from the Visor to the ASB bus. Using this basic design framework, a developer of Springboard expansion modules can take immediate advantage of the performance and the variety of peripherals available for the ASB bus. Furthermore, using the same translator and merely changing the interface to the external bus, a Springboard developer can take advantage of peripherals developed for other external buses as well.
The present invention provides for a bridge between a host system and an external bus, where the host system includes a host processor and a host bus that provides an expansion interface. The host processor serves as the master of the host bus, and the external bus can serve as a part of a slave on the host bus. For example, a multi-master ASB bus can be bridged to the single-master Springboard bus of the Handspring Visor. In this case, the Visor""s Dragonball processor is the master of the Springboard bus, and the combination of the bridge and the ASB bus is a slave. A user can thus be provided with the performance and flexibility of the ASB bus, while retaining the familiar, ergonomic interface associated with the Visor (and other Palm-compatible computers).
A developer for the relatively new Springboard platform can take advantage of the existing library of design modules available for the relatively mature ASB bus. Thus, the invention provides a rapid development platform for the competitive Springboard-compatible marketplace. Even where every function desired by the developer is not provided in the ASB library, the number of functions that must be met by designing new modules is greatly reduced by the present invention.
In general, to the extent that new module designs are required, they can take advantage of the features of the external bus. If the external bus is a multi-master bus, the new modules can function as masters on the multi-master bus and/or can take advantage of additional computing power made available by other masters on the multi-master bus.
A serendipitous additional advantage of the invention is that functional modules developed with the PDA platform in mind can have a bigger-than-intended market. For example, ASB bus peripherals developed for the Handspring Visor are then available as library modules for non-Springboard applications utilizing the ASB bus. Accordingly, the present invention allows development costs to be distributed over a larger-than-expected marketplace. Thus, the present invention can lower development costs attributable to the originally intended application. This advantage is in addition to the afore-mentioned advantages of more rapid development for the developer and more computing power to the user.
The present invention further provides that the bridge can include a translator between a host-bus protocol associated with the host (e.g., Springboard) bus protocol and a target-processor protocol associated with a target processor (e.g., the Arm7). In this case, the bridge further includes a processor-to-multi-master bus interface that translates from the target-processor protocol to an external-bus protocol. Dividing the bridge in this way simplifies the task of bridge design since it can take advantage of an existing processor-to-external-bus interface, e.g., an existing Arm7-to-ASB interface.
In the case of a Springboard to Arm7 translator, a complete translation is not possible. The Arm7 responds to a xe2x80x9cwaitxe2x80x9d signal while a data transfer is in progress, while there is no corresponding signal in the Springboard protocol. Accordingly, the translator can include a state machine that monitors signals that indicate when each of the buses begins to treat a data transfer as complete. These indications can be used to validate (or invalidate) data transfers.
A method implemented by the bus bridge with translator begins with a data-transfer request, originated by the host processor, and output from the host bus in conformity with the host-bus protocol. The bridge translates the request into the target-processor protocol, and provides the request in that form to an external-bus interface. The external-bus interface translates the request from the target-processor protocol to the external-bus protocolxe2x80x94in which form it is provided to the external bus. A bridge state machine can monitor signals that indicate when each of the buses begins to treat the requested data transfer as complete. If the host bus begins to treat the data transfer as complete before the external bus does, the bridge can indicate an error condition.
In the case the external bus might otherwise respond to a write request so fast that it writes data before it is valid, the state machine can include a write-wait state during which the data can complete its transition and before the write request is forwarded to the external bus. A counter can be used to count a number of external-bus clock cycles matching the duration selected for the write-wait state. The counter can be a down counter that is continuous reset to the selected number of clock cycles in every state but the write-wait state.
The expansion module can provide for a low-power mode when maximal performance is not required. In low-power mode, the external-bus clock frequency can be reduced to save power. In this case, the number of cycles corresponding to the desired write-wait duration is reduced. Thus, the invention provides for changing the write-wait count, for example, as a function of bus-clock frequency.
There is a surprising additional advantage to using a bus-to-processor protocol translation in the bus bridge. The bridge can be readily modified to accommodate other external buses. The translator remains the same; only the bus interface is changed. Thus, the design effort required to interface to one multi-master bus serendipitously provides for interfaces with other buses for which interfaces exist for the same processor. Thus, for example, a Springboard/Arm7 translator can be used in bridges to non-ASB buses for which Arm7 interfaces exist or are being developed. Thus, the invention makes it convenient to select from a variety of external buses for coupling to the single-master bus. A selection can be made based on different capabilities of the external buses themselves and/or on the contents of their associated design module libraries.
In accordance with the foregoing, the present invention provides a design method for expanding the capabilities of a system with a host processor and a single-master bus with an associated expansion interface. In the first step, an external bus is selected, e.g., based on performance and/or availability of design modules.
In the second step, a target processor is selected. In general, the target processor selected is one for which an interface to the selected external bus exists. To minimize the numbers of protocols and interfaces a developer must contend with, a processor planned for actual use with the external bus in a product design would be favored over a processor not planned for such use in selecting a target processor. For example, if interfaces for both an ARM7 and an Intel Pentium are available, but only the ARM7 is to be used as a bus master for the external bus in an Springboard expansion module, then the ARM7 would be selected over the Pentium to provide the target processor protocol for the translator selected in the third step.
In the third step, a translator between the host bus and the processor protocols is selected (if available) or designed. In general, this translator can include a state machine that coordinates the protocols and an interface to the host bus. Finally, the translator is coupled to the host-bus and to the external-bus interface, and the external-bus interface is coupled to the external bus.
In a more straightforward method, the desired functionality would be designed directly for the host bus, e.g., the Springboard bus. In principle, this straightforward approach allows the desired functionality to be achieved with greater simplicity and reliability. If multi-mastering is required, the straightforward approach would be to bridge a multi-master bus designed with the host bus in mind directly, without emulating a processor.
In practice, these advantages can be more than offset by the more rapid development afforded by the present invention. The tradeoff is even more favorable when it is considered that peripherals designed for the host bus are also compatible with other applications that use the same external bus. In addition, the invention makes it easy for one host bus to access the features of alternative external buses. These and other features and advantages of the present invention are apparent from the following description with reference to the following drawings.